Hey Antoine, looks really good so far.
Are you also going to work on a set of generic debug messages to communicate with the UI?
It would be really nice if we can keep having a generic frontend and backend such that we can connect to other debuggers, too. So you would translate the parsed MI protocol information to more generic debug protocol messages?

Also could you put the 'gdb' word into the module path to indicate that this is not a generic debugging facility but rather the gdb extension?

Parsing the streams of running process and forwarding them to a terminal in the UI could be useful in other scenarios, too. Do you think it would be feasible to allow registering console parsers on the backend, that get activated on specific situations, for instance if gdb gets started? Maybe that way we could start processes on the backend, have their output parsed and still allow the user a full terminal to interact with the process. It would be nice if we don't need a new terminal for each such case.

Yes I plan to have a generic debug API but maybe not the way it's been traditionally thought of.

Things I'm considering right now:

• It needs to be extendable to any debugger.
• The debug session state should be directly mapped to the UI
• The debug session state should be in the backend. (So that you don't lose your session or for sharing)
• The UI should be as generic as possible but allow extensions.

So to answer this I'm thinking about using:

• Vue for the UI
• Vuex for the state
• Apollo / GraphQL for the Frontend -> Backend protocol here's an example.

The main things is this last line, my current thinking is that there's no need for a middle ground API layer for debugging. In the end what Theia cares about is what is displayed in the UI. So if we can just map the UI to state queries and handle those we may have a generic api that will work with any UI.

We just need some negotiation between the frontend and the backend to see what schema they can agree on and then display the UI that can be displayed based on the backend schema.

This seems way nicer than with JSON-RPC. WIth that I would need to do like:

Frontend <---------------------> Backend
UI <-> API <-> <---JSON-RPC ---> API <-> State <-> Debuger

And this API would be quickly complicated, how to make it generic for any UI and any debugger ? It would need extentions etc... and I think that will be hard to manage.

WIth GraphQL I think it can be:

Frontend <---------------------------> Backend
UI -------> <--- GraphQL (json) ---> GraphQL Server <-> State (vuex) <-> Debugger

Note that since much of the UI are direct requests to State I expect the GraphQL Server part will contain mostly pure actions like adding a breakpoint. And all the rest will be a direct mapping UI to State. The complexity will reside in the actions implementation and only in this one place. Rather than at both ends of the backend /frontend + all the state data marshalling.

This should make it easy to develop a UI too since the API will be basically just: request your data here's the schema for it.

And it's BSD-3 licensed so we can use it :)

Note that all this looks good on paper but I really need to make a proof of concept of it... WDYT ?
Note also this pattern may be applicable in other places in theia... not sure yet.

Also about the module, it is generic and not GDB specific, the specific parts are in the MI directory and even that is not GDB specific (could work with lldb). The only gdb specific part is GdbDebugSession.ts and the tests... I needed something to test with...

About the terminal, with the refactoring patch I pushed you can create a terminal with any endpoint so in a way you can already do that for any command that is started so long as you expose it from the backend.

The missing parts are:

• A registry of these console in the backend ?
• A generic backend module to expose a terminal based on a process.

I think these will get worked on in conjunction with the build/launch modules and possibly #154 as we generalize the widget manager etc... I think it would make sense to generalize the backend services that are linked to some UI too. I'm not clear how to manage those mappings yet however.

But yes indeed I'll work in that direction.

Interesting, I guess I'll have to look into GraphQL to understand the advantages you listed.

Frontend <---------------------------> Backend
UI -------> <--- GraphQL (json) ---> GraphQL Server <-> State (vuex) <-> Debugger

Isn't vuex usually used in the UI process and not on the backend?

Yep you may be interested about this podcast (changelog) about it.

For vuex and the backend, yes it is usually in the frontend, a more appropriate diagram could have been

UI <--> local state (vuex) <-----> GraphQL Server -> Server state (vuex?) -> Debugger

Vuex might not be the best thing for this backend side... this link is interesting .
It might just be that a graphql server <--> some data store, maybe sufficient indeed.

There's still much to do to iron this out, but I think the general idea works.

Is not it very bound to vue/vuex? With JSON-RPC other technologies can be used to implement backend, as Java. Is it possible with vuex? How one provides java-backend? What will be the technology-agnostic protocol specification?

@akosyakov The tech agnostic protocol is GraphQL, vuex is just a state data store it could be replaced with any data store.

Here's a more generic example:

Frontend Backend
UI (Anything vue,phoshor...) <----- GraphQL ------> GraphQL Server (implemented in anything) -> DataStore

Ok, looking forward to a prototype. It would be interesting to see something simple that shows extendibility of this approach compare to a JSON-RPC solution.

If the debug extension will be one of core extensions at the end, it would be nice if it does not solve the same issues in a different way to other extensions. There should be a good a case to add new dependencies and have several ways to solve similar issues.

Yes, like I said I think this approach could be used by other extensions too. Especially if they are data driven. The idea that you specify the types of what you query and then just request the data is very powerful imo compared to defining an API.

Using a prototype should it should be more clear. I'll hopefully work on that soon but it will take some time...

You may find this blog post from github (they're using graphql now) interesting too as they compare to REST: https://githubengineering.com/the-github-graphql-api/

@svenefftinge btw I think you're right about the gdb directory module

I will make it so that

debug: This module enables registration of the different debuggers and selecton of the right debugger for the project.

gdb: Module for the actual debugger

This has been inactive for months. Can it be closed?

yes, let's close it.